ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group97b.txt/000027_icon-group-sender _Wed Jul 16 00:22:25 1997.msg

Internet Message Format | 2000-09-20 | 6KB

Received: from kingfisher.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Fri, 18 Jul 1997 15:09:51 MST
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA05692; Fri, 18 Jul 1997 15:09:50 -0700
Date: Wed, 16 Jul 1997 00:22:25 -0500
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: [e-mail]
Subject: Is comp.lang.icon still alive ?
To: [e-mail]
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: [e-mail]
Status: RO

>Sometimes I wonder. I just skimmed through >20 postings, none of which was
related to the Icon language, some 3 of them were remotely related to
computing. There was not even any of the classical mistakes of `Where can I
get this cool graphic icon editor ?'.

:-(  In part, remember that this is summer, where a lot of the educational base
of Icon's support is away for the summer holiday.  Once the universities are
more active again, I expect the traffic to pick up.

>The FAQ hasn't been updated in ages. Were it not for the icon newsletter,
you would believe the language is dead.

It is posted periodically, and it's not clear that there's a whole lot of
updating that it needs... is there?

I would like to see some serious effort given to getting the Icon story out to
Webmasters for use in CGI scripting, and possibly even adapting the interpreter
somewhat to make it more "CGI friendly".  This is an area where there is a huge
and growing interest in the user community, and I think perl is still vulnerable
there (if you have to learn a new language, Icon seems at least as reasonable as
perl does).  On the other hand, that particular window of opportunity will not
stay open forever.

>So I will try and write something a little more Icon-related.
I've been working on an Icon port to the Amiga, and so has Marc Culler.
Fortunately, our parallel work have been mostly in complementary direction,
so there should be a new twin port  that compiles under both SAS/C
(amiga-centric) and gcc (Unix-like close port).  The main work that remains
to be done is... drum roll... the graphics part.

Somehow I'm not surprised by that.  :-)

>I've seen the Unix and Windows version taking shape. Having at least two or
three distinct ports will be a very Good Thing, as we will get the chance
to get more platform independent graphics. Right now, the control you have
on colormaps is a bit too simple, for instance.  You can play with images
as long as you stay within the Palette ranges, for instance, or as long as
you don't allocate more colors than your display can handle.
Playing with digitized images is much more difficult. Maybe I haven't
looked closely enough, but it seems there is now way to ask for `the
closest color to those already in use' except for the hard-coded palettes.

The problem with graphics, like fancy printing perhaps, is that there is the
traditional tradeoff of "fast/good/cheap, pick any two" with hardware
independence thrown additionally into the pot somehow.  Graphics suitable for
high-quality image processing is probably at odds with fast sprite-type graphics
suitable for games development, for instance.

>Right now, I have to whip up another external graphics program to first
correct my colormap, and then to play with Icon.

I don't come to Icon with the sense that it's a language that's ideal for
*everything*.  For most general things, I find I still prefer S*BOL.  For
database-type business-y things and report generation, I find FoxPro is
generally pretty good.  For asynch communications stuff, I like SALT scripts
within the Telix comm package.  For really fast low-level stuff, I personally
still find assembler the most satisfying (although few clients are willing to
pay what it costs to develop in it).  C is a good though primitive language for
some kinds of development (I wrote a mouse-driven graphical editor for
programming a computerized monumental water fountain in it, for example).  And
other stuff, especially combinatorial problems or those best suited for things
like character sets and such, Icon is simply unbeatable.

>I would say that colormaps are an important object in their own right, that
deserves a more thorough concept.

Fine, but it's hard to get everyone to agree on anything that's both general
enough to be hardware independent, and efficient enough to do the things you
want to be able to do.  Coming up with a good "model" which will conceptually
still be reasonable five or fifteen years from now is a bit tricky, I'd think.
(OTOH, if anyone can do it, I think Griswold and his crew are probably some of
the more creative and imaginative people out there).

>As another limitation, I've compiled Icon 9.3 under Amiga OpenBSD... Works
withouth a hitch, BUT my X display is rather peculiar: I only have 4 color
planes, for a grand total of 16 possibly different colors. Most icon color
programs tend to allocate more than 16 colors, and so fail abysmally on my
machine... though I'd like to get more use of it than out of a b&w machine.
Contrasting with that, other programs such as the pure amiga port of
Ghostscript manage to produce awesome color graphics with the same
limitations.

Having at most sixteen displayable colors is a pretty severe limitation anymore.

>Just wanted to give all the comp.lang.icon lurkers the feeling they were
not abandonned yet :-)

I believe that the comp.lang.icon messages are echoed to this mailing list...
but does anybody echo these mailing list messages back to the newsgroup (at
least the ones that weren't ALREADY echoed from there to the mailing list?)

Gordon Peterson
http://www.computek.net/public/gep2/
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/